Trying
to focus on the thousands of settings will certainly hurt your mind a
bit. Over time, you will remember settings or keep a log of which ones
you feel are required, but to begin with, you should start with small,
easy-to-grasp settings so you can see immediately if and how your
policies are being applied. Before you begin, however, it is a good
idea to gain a full understanding of what Group Policy settings do and
how they work.
Group Policy Objects
You
can apply a Group Policy object (GPO), which is created within Active
Directory, to particular systems or users. A GPO is made up of two
parts: a Group Policy container (GPC), which lives within Active
Directory, under the System\Policies
container and is replicated with Active Directory items, and a Group
Policy template (GPT), which is stored in the SYSVOL folder.
Note
SYSVOL
is a collection of folders that contain a domain’s public files,
including logon scripts, GPTs, and system policies. In Windows Server
2003, SYSVOLSYSVOL folder is replicated through Distributed File System (DFS) replication. was replicated using
the File Replication Service (FRS), but with Windows Server 2008, if
the domain is upgraded to the Windows Server 2008 domain functional
level, the
The Group Policy Central Store
In
addition to the typical settings within Group Policy, Microsoft
provides template files (previously called ADM files) that you download
in order to manage items through Group Policy. A good example of this
is Microsoft Office templates for Group Policy.
With
legacy versions of Group Policy (Windows 2000 Server/Server 2003/Server
2003 R2), there is too much replication occurring with the SYSVOL
folder because the GPT included all the default Group Policy templates
and any ADM templates for the GPO, and they replicated (with a minimum
of 4MB each) around the entire domain. That made for excessive
replication.
Instead of having all the templates replicate, the solution is to point everyone to a single central store.
Note
The
template files that were previously called ADM files have been split
into two parts, ADMX and ADML. ADMX holds the settings, while ADML
holds the language. So, in Windows Server 2008, a single ADMX can have
multiple ADML files that support multiple languages. This allows
administrators in various countries to read Group Policy definitions
that have been established in their own language.
To create the central store, you have to perform the following steps:
1. | Log in to any domain controller as an Administrator for the domain.
|
2. | Create
a new folder in the SYSVOL folder called PolicyDefinitions. That folder
is typically c:\Windows\SYSVOL\domain\Policies\PolicyDefinitions.
|
3. | Create a subfolder in the PolicyDefinitions folder for each of the languages you need to support (for English, it is \en-US).
|
4. | When
the central store is created (it is empty at the moment), add templates
that you want to use. To find templates, go to the
c:\Windows\PolicyDefinitions
folder on a Windows Vista or Server 2008 system and copy the ones you
like. Keep in mind two points: You need the ADMX and the ADML files
(and the ADML will go in the language folder you created). Also, you
should not copy all these—only the ones you need.
|
The Application Order of Group Policy
You
can create and apply Group Policy in a variety of ways. Within Active
Directory, you can apply GPOs at the site, domain, and organizational
unit (OU) levels. In fact, with OUs nested within other OUs, you can
apply policies at every level.
However,
a local system may also have policies applied. Pre-Vista systems had
only one local Group Policy, whereas Vista and Windows 7 systems allow
for Multiple Local Group Policy Objects (MLGPOs).
Group
Policy is relatively easy to understand when you have one policy
applied to one OU, and a user logs in and receives those policy
settings. That seems to make perfect sense. But what happens when there
are policies at the site level, the domain level, the OU level, and the
local level?
When
local policy settings conflict with Active Directory policies, the
local settings always lose. Beyond the local level, the order of
precedence is site, domain, OU (with OU taking the highest precedence).
For
example, if you have wallpaper settings in several policies which state
wallpaper should be blue applied to the site level, green applied to
the domain level, and yellow applied at the OU of a user named John,
and John logs in, the wallpaper will be yellow. If, however, there is
no conflict, and each of those policies has different settings that can
be applied, they will accumulate, and all settings that do not conflict
will be applied to the user or computer.
Note
A
Block Inheritance attribute can be selected to stop the application of
policies from higher levels of precedence. However, if an administrator
wants to force a policy setting to be applied down to the lower levels,
he can set the Enforced setting.
